Support granular UI annotations and labels #132
Conversation
|
@woz5999 Are the UI pods the pods within the backend deployment? Those pods would be:
I can see that the Is your primary concern having a separate annotation which exclusively targets pods within the |
|
@bdjohnson529 That's correct. Our service mesh leverages annotations for registration and routing. Currently, if we set the annotation for the "backend" is applies to the workflow pods as well, meaning that UI requests regularly get round robin'ed to non-UI pods, resulting in HTTP errors. By being able to target the UI pods individually, the issue is totally resolved. |
|
Hey @woz5999 , Jason from Retool's infra team -- the PR makes sense to me, but we don't internally call these non-workflows pods "ui", so checking with our team on what we'd like that naming to be. |
|
Sure thing. Naming's hard. Just let me know when you're ready and I can happily update. |
|
Hey @woz5999 , we talked internally and we're good with using Once you do that I'll merge and release this change for you. Thanks! |
|
@jjlgao done. let me know if you need anything else |
|
The linter is failing because the chart version needs to be updated. I'm happy to do that. I'm guessing 6.1.0 should be the new version? |
6.0.9, thanks! |
|
Done |
|
Thanks everyone. When do new releases get published to your helm repository? |
|
They're done manually. I'm going to publish it in a bit. |
|
Just published, try pulling now! |
This PR adds the ability to specifically target the UI pods with annotations. The current available annotations configurations apply to multiple deployments, including the UI pods. In order to expose the service via our service mesh, we need the ability to target the UI pods with annotations. This change allows us to inject and expose the UI pods only, without inadvertently annotated undesired pods.
if you need me to make any changes like bumping versions or updating changelogs, etc, just let me know and I'm happy to do so.